Subject: HPR Route Preference

From: [email-masked]
Date: Wed, 2 Nov 94 16:59:24 EST

>You completely missed my point.  By saying "if the optimal route was HPR
>only it would have been chosen" means just that - optimal - as is best -
>as in least cost - as in better than ISR TGs.  So if networks are
>correctly migrated to HPR, there is no need for the coercive method you
>are proposing.

Mark, I didn't miss your point at all.  I simply don't agree that for many
networks that gradually phase in HPR over a period of time, it is as simple as
you make it sound.  Just consider how TRS goes through the process of
preferring TGs.  When comparing one TG to another to determine which
is preferred, the only thing being compared are the TG characteristics
(X'47'CV) of the two TGs against the allowable characteristics ranges for the
COS preferred by that session.  That is how TRS determines the best path based
on COS.  There is no characteristic in the X'47' that says whether the TG
connects two HPR-capable nodes.

This means that two TGs can have the same characteristics (or have different
characteristics but fall in the same COS ranges, therefore have the same
weight), yet one may connect two HPR nodes while the other may only support
ISR.  Although the "HPR" TG allows for dynamic path switch capability, and
probably much better routing performance also, in this case it's given
equal weight during route selection.  Think about it.

I mentioned in my previous note that network managers have some control in
making HPR TGs preferrable by monkeying with the characteristics of HPR TGs
and ISR TGs.  I.e. they can change something like effective capacity or
propagation delay, which normally indicate the physical characteristics of
the link and not the software capability of the nodes connected by it, to
make HPR TGs more preferrable.  This is NOT easy to do with complex networks,
and in some cases is going to be darn near impossible.  Or they can use one
of the user-defined characteristics, but that will probably require them to
redefine all of the TGs in their network.  That doesn't make APPN look too
dynamic.  Even all of this manual definition can cause serious problems.

For instance:
If any ISR TGs fall in the
"top row" of any COS tables, it won't matter what you do to the HPR TGs.  They
will never be preferred over those ISR TGs for those COS's.  But if you try to
redefine ISR TGs so that they don't fall in the "top row", now the HPR TGs,
when matched head-to-head with an ISR TG, will ALWAYS be preferred, and could
result in serious load balancing problems in the network, because every session
is choosing HPR paths.

I realize there are tools that help to 'doctor up' TG characteristics based
on % session traffic desired, but they are far from perfect, and probably
can't do this doctoring at all based on HPR desireability.  That is what
this proposal is all about.  It lets managers dictate when a particular
session prefers HPR.  They even have the capability of assigning HPR paths
to some sessions orginated by a node, and granting no preference at all
to other sessions on that same node, and ALL are using the same COS.  This
cannot be done without a function like this proposal.  Managers are given
greater ability to control how their networks are used.

+ If, for example, a path existed in a network that was more desireable for
+ the COS #INTER, and every user was using the #INTER COS to communicate and
+ had access to that path then that path would be built by TRS every time.
+  Same problem.
+ Since operators have managed to avoid load balancing problems with the
+ 'coercive' COS method APPN uses, I believe they will manage to avoid load
+ balancing problems when adding the mechanism to allow users to prefer HPR,
+ as opposed to interactive or batch, paths as well.

>If this method is so bad, then why are you essentially doing the same
>thing with your method?  There is already a way to prefer a certain
>route given a specific COS and you are now defining another way to do
>the same thing that doubles your route calculation expense when there is
>not an HPR path available.

Because there are numerous problems associated with using a COS to prefer
HPR routes.  First of all, there is no SNA-defined COS (#inter, #batch, etc.)
that prefers HPR, without 'doctoring up' all of the TGs, and then you have
to deal with the problems I stated before.

So let's assume a user-defined
COS is created that has a user-defined field indicating whether HPR is
supported by both partner nodes.  YES means lower weight for that COS, NO
means higher.  Every end node and every network node server that supports
at least one session that prefers HPR must have this COS table manually
defined.

Also, assume that this value defaults to NO for TGs that don't have
this defined.  Now all HPR TGs have to be redefined to indicate YES in this
field (if there isn't a default, then all TGs in the network have to be
redefined).  Many users just accept the defaulted values for their TG
characteristics.  They can't do this anymore with a user-defined HPR COS.

Also, every session that wishes to use the COS must have its MODE name mapped
to that COS.  This requires all of these modes to be redefined for every
end node that wishes to use that COS.

Using the HPR preference proposal, managers only have to modify the mode
names, for sessions using that mode and prefer HPR paths, to indicate an
HPR preference.  No new COS tables to create, no manual definition of TG
characteristics.  It is much less definition.  It allows HPR paths to be
preferred for ANY COS, including the SNA-defined COS's.  It gives managers
the flexibility to specifically pick and choose which sessions will be
given HPR paths by assigning them to a mode that prefers HPR.  It guarantees
that an HPR path will be chosen if one exists that can carry that session.

>It is required where you want to do have this new method of route
>calculation.  So instead of getting the networks built correctly, you
>force all the endpoints to change their mode definitions.

No, only endpoints where HPR paths are desired.  Actually, you want to be
selective as to which nodes will prefer the HPR paths.  If every
session preferred HPR paths, then all traffic would go over the HPR portion.
Just like if every session preferred #INTER COS, and some paths in the
routing backbone had lower weights for #INTER, then all traffic would go
over those paths.

Tim